テストのピラミッドを開発者と一緒に眺めてみよう！

はじめに

事業開発部でQAエンジニアをしている長友です。

品質シリーズの投稿です。

今回はテストピラミッドについて書きます。

2018年のJaSST Tokyoの基調講演で登壇されたGoogleの方が、全部自動でテストしていると話されていて度肝を抜かれたのを覚えています。
また、招待講演で登壇された方に、講演でお話された開発時に自動でテストしていた内容を聞いたときには、なんて先進的なテストをされているんだとびっくりしました。

そんな自動テストを作っていくときの参考になる内容です。

今回も開発者の方とお話されるときのネタしていただけたらと思います。

テストピラミッドとは

テストピラミッドは、さまざまなテストのレイヤーについて考えるようにと、視覚的に示して教えてくれるモデルです。

最初にテストピラミッドについて書かれたものは、Mike Cohnの「Succeeding with Agile」という本です。

またその後いろいろな方々が書かれています。

各レイヤーで実行するテスト量を示し、またテストにかける工数の目安とも言えます。そして、どのテストを充実させたらいいのかなどの判断の参考にもなるものです。

図の中の文字は以下のような意味です。

• ST：システムテスト
• IT：インテグレーションテスト
• UT：ユニットテスト

※今回の説明用に記載したもので、皆さんのところでは、どんなレイヤーでのテストを行っていますか。それぞれで実施しているテストの内容に読み替えてご覧ください。

ピラミッドの見方

ピラミッドの上の方にいくほど、

• エンドツーエンドで動いて、ユーザーと同じようになっていて、
• テストの実行速度が遅く、
• 開発者の方へのフィードバックに時間がかかって、
• 大変で、不安定で、
• 信頼性が...、結果が一意にならないことも...
• 高コスト

です。

逆に、ピラミッドの下の方にいくほど、

• 局所的で、
• テストの実行速度が早く、
• 開発者の方へのフィードバックも早く、
• やりやすく、安定していて、
• 信頼でき、結果が一意に決まり、
• 低コスト

です。

さまざまな自動テストを作るときに、このテストピラミッドの形になるようにするのがいいですよということです。 まずは、

• 新しいテストを追加するときには、まずUTで対応できないか確認します。
• テストは、常にピラミッドのなるべく下のレイヤーに入れるようにします。
• ピラミッドのすべてのレイヤーにおいて、チームメンバーと協力して、無駄や重複を避けます。

といったことを考えてみるといいです。

(参考)ジョナサン・ラスマセン「初めての自動テスト」(「アジャイルサムライ」を書かれた方が著者)

現状がこうなっていなくても

とはいえ、最初からこんなにきれいに三角形をしたものを作れていなくても大丈夫です。最初は現状をチームで把握していくことが始まりです。
たとえ下のような逆三角形になっていてもいいんです。
いきなりたくさんのテストを書くことができない場合に、テスト対象の外側のレイヤーから段々とテストの自動化を進めていくことも有効なので、こうした形になっていることもあります。
チームの皆さんで、どうしていこうとか話し合っていくことが大切です。

そして、上のレイヤーで動作確認できるものを用意しておいて、そこから下のレイヤーのものを増やしていきます。下のレイヤーのものが増えて、十分になってきたところで、上のレイヤーのテストで削除可能なものを削除していくという方法でピラミッドを整えていくこともできます。

上のレイヤーのテストは、不安定だったりします。そのため、失敗する場合も多いことがあります。
テストが信頼できないと、テストが失敗しても無視してしまうようになります。また開発者の方々などの精神衛生上もよくない状況です。

だから、そうしたことも防ぐためにも、テストピラミッドを意識しつつ、開発者の皆さんとお話して、改善していきましょう。

テストの種類

テストピラミッドの各レイヤーごとのテストは何を表すのでしょうか。

各レイヤーのテストは、各レイヤーに対応する開発プロセスのできを確認するためのテストであることが多いと思います。 私の所属する部署で開発を行っている「prismatix」では、1つのスプリントで全部のレイヤーのテストを実施しています。

UTでは、少なくともクラスのパブリックインターフェイスをテストします。

ITでは、システム内の他のサービスに接続されたサービスのスタック全体をテストします。

STでは、全てのサービスをスタブなどを使わずにつなぎあわせてテストをします。

ただ、この表現は漠然とした一般的な内容にしています。こちらについても、それぞれの皆さんのところの状況で読み替えたり、レイヤーの分け方なども変えて、考えてみてください。

マイクロサービスでのテストピラミッド

マイクロサービスでは、テストをするのが難しいことがいろいろあります。

プロセス間の通信がいろいろあり、APIもどんどん拡張されていきます。

ですので、自分が開発しているサービスと依存するサービスやクライアントとの連携の処理を確認するために、テストコードを書くことは、開発者の皆さんにとって、とても大事なことです。

テストのレイヤーの分け方もそれぞれで考えて、見直していくことが必要です。

レイヤーの分け方により、原因の切り分けのしやすさが変わってきたりします。スタブをどれくらい使っているかによってもテストのやりやすさなども変わってきて、適度な感じに分けるのが大切です。

「マイクロサービスパターン」という本では、先に示したテストピラミッドよりもう1つレイヤーが多くなっていて、STとITの間にコンポーネントテスト(CT)というものが加えられています。各レイヤーの内容もこれまで話しているものと少し違うものになっています。

コンウェイの法則と逆コンウェイの法則ではないですが、皆さんのところのテストがやりやすい、やりにくいを変えていくのにも、テストピラミッドのレイヤーなどについて話してみてはいかがでしょうか。

アジャイルテストの4象限

唐突にタイトルが出てきましたが、最後にアジャイルテストの4象限というものをあげて、いろいろテストがいるんだなぁと思ってもらって、終わりにします。

テストは、UT,IT,STが終わっていたら終わりなんでしょうか。他にも実際にはされていると思います。負荷テストやセキュリティテストなど。

機能のテストとかが多くなってしまうこともあります。ただ、他にもいろいろ確認しないといけないということです。

アジャイルテストの4象限というものでは、ビジネス面と技術面という軸とはほかに、チームを支援すると製品(サービスも含)を批評するという軸で分けた、4つの象限でテストを分類しています。各象限の順番にテストしましょうというものでもなく、実際に早く負荷テストしたほうがいい場合もあります。ただ、どれかだけでなく、広く確認をしておくことが大事ということです。
また、それら確認の必要なテストを完了することをきちんとバックログに積んでおいて、スプリントプランニングで、実施することを計画しましょう。
そして、そのバックログが消化される状況などを、チームの皆さんで話して、品質のよいサービスを作っていきましょう。

今回はここまでです。

また次回をお楽しみに！